Skip to content

Resolve route bug for MacOS #2548

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
happyharryh wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

Resolve route bug for MacOS #2548

happyharryh wants to merge 1 commit into from

Conversation

@happyharryh
Copy link

@happyharryh happyharryh commented Dec 22, 2025 •
edited
Loading

Starting from MacOS Tahoe, running ZeroTierOne may corrupt the operating system’s routing table and DNS configuration (#2520 ). The occurrence of this problem depends on the network environment (not happen in all environments). In certain network setups, when Allow Managed Addresses is enabled, either immediately or after running for a period of time, the OS routing table and DNS become unusable. In the past three months (after updating to MacOS Tahoe), I have to disable Allow Managed Addresses and manually add the virtual IP by sudo ifconfig feth537 inet xx.xx.xx.xx/24 up.

These days, by debugging, I found that this issue is related to the code in MacDNSHelper.mm. As shown in the code, skipping the configuration of State:/Network/Service/%.16llx/IPv4:Router in SystemConfiguration can prevent this problem from occurring.

The logic of the setting was introduced in commit #1d095e8, seemingly to fix network DNS on macOS. However, starting with MacOS Tahoe, Apple appears to have changed certain behaviors related to SystemConfiguration, causing the breaking.

Here is my environment:

MacOS 26.2
ZeroTierOne 1.16.0
allowManaged = 1
allowGlobal = 0
allowDefault = 0
allowDNS = 0

In my network environment, applying the modification of this PR restores normal behavior. However, I am not sure whether this change could introduce other issues, for example when the settings of allowGlobal/allowDefault/allowDNS changes.

I would appreciate if maintainers or others who can build and test ZeroTier could help verify this PR.

UPDATE:
Wed Jan 21 10:56:29 CST 2026, I have built the commit in this PR by Github Action. MacOS users are welcome to try zerotier-one-mac by replacing /Library/Application Support/ZeroTier/One/zerotier-one (after backup) followed by restarting the service.

@CLAassistant
Copy link

CLAassistant commented Dec 22, 2025 •
edited
Loading

CLA assistant check
All committers have signed the CLA.

@happyharryh happyharryh mentioned this pull request Dec 22, 2025
Open
@ihexon
Copy link

ihexon commented Jan 9, 2026 •
edited
Loading

In macOS 26.2 (Build 25C56), ZeroTier One built from the latest main branch commit
8d4cb1e no longer appears to exhibit the previously observed routing issues.

➜  ~ sw_vers
ProductName:		macOS
ProductVersion:		26.2
BuildVersion:		25C56

➜  ~ route -n get default

route to: default
destination: default
mask: default
gateway: 192.168.1.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
0         0         0         0         0         0      1500         0

Based on this limited testing, it appears that Apple may have addressed the underlying issue at the OS level.

However, this is purely anecdotal, and confirmation from other users and environments would be helpful to determine whether the problem has been fully resolved.

UPDATE:
Sat Jan 10 19:16:59 CST 2026, the bug still exist

@happyharryh
Copy link
Author

happyharryh commented Jan 14, 2026

In macOS 26.2 (Build 25C56), ZeroTier One built from the latest main branch commit 8d4cb1e no longer appears to exhibit the previously observed routing issues.

➜  ~ sw_vers
ProductName:		macOS
ProductVersion:		26.2
BuildVersion:		25C56

➜  ~ route -n get default

route to: default
destination: default
mask: default
gateway: 192.168.1.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
0         0         0         0         0         0      1500         0

Based on this limited testing, it appears that Apple may have addressed the underlying issue at the OS level.

However, this is purely anecdotal, and confirmation from other users and environments would be helpful to determine whether the problem has been fully resolved.

UPDATE: Sat Jan 10 19:16:59 CST 2026, the bug still exist

I have built the commit in this PR by Github Action. You can try it.

@vint2k
Copy link

vint2k commented Jan 16, 2026

This helped me solve issue #2520. I tested it for about 5 days and it works great.
@happyharryh thank you!

@laduke @adamierymenko please check this PR. The community needs a bugfix release.

@happyharryh happyharryh deleted the branch zerotier:dev January 21, 2026 02:48
@happyharryh happyharryh deleted the dev branch January 21, 2026 02:48
@happyharryh happyharryh restored the dev branch January 21, 2026 02:49
@happyharryh happyharryh reopened this Jan 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@happyharryh @CLAassistant @ihexon @vint2k